The invention relates to network management and, in particular, to methods and systems for the management of routes in telecommunications networks.
In today""s large telecommunications networks such as core networks used for Internet service providers (ISPs) or major corporate backbones, network management plays an important role in maintaining network stability, performance and efficiency. Network management is used to perform a variety of functions including the detection and correction of fault conditions, the identification, configuration and monitoring of use of network devices for cost allocation and performance evaluation.
Presently, the vast majority of networks are managed at the physical or device level by a centralized management entity commonly referred to as a network manager server (hereinafter xe2x80x9cnetwork managerxe2x80x9d) whereby devices in the network such as routers and physical layer interfaces are each individually polled by the network manager for status updates. However, in many situations, this process is not time-efficient.
For example, in the event of a congestion point causing unusual traffic delays or a failure causing a traffic interruption along a particular routing path, each network device located along that particular path and involved in the transmission of the traffic delayed or interrupted as a result of the congestion point or failure must be polled by the network manager to locate the source of the problem. Polling multiple devices each time a problem arises along a particular routing path is therefore time-consuming and as a result, substantially lengthens the time necessary to solve the problem.
Because polling of multiple network devices is time-consuming, most problems encountered in a network may deteriorate or improve by the time a network manager is able to track down the root of the problem, making it more difficult to ascertain its true nature. Moreover, in many cases, clients only report network problems long after their occurrence which, by that time, may not be visible problems anymore. This is particularly true of congestion points which are intermittent by their very nature and only occur in heavy traffic conditions.
In ascertaining the nature of a particular problem, it is often necessary for the network manager to determine which clients are affected and the manner in which these clients are affected. This typically requires a network-level analysis of each problem by considering the performance history of the particular routes and paths used by each client. A route is a static concept typically defined by a source endpoint and a destination endpoint in a network. By contrast, a path is a dynamic concept associated with a particular route. A path is defined as the set of network devices and their respective interfaces traversed by traffic travelling in a particular direction at any given point in time on the particular route. Paths in a data network are usually dynamically determined by a router protocol.
However, current device-level management applications do not provide the necessary tools for efficiently monitoring routes and paths. As a result, these problems become virtually impossible to solve and may persist indefinitely. Therefore, there is a need to provide network operators with the ability to monitor the performance history of routes and paths for efficient troubleshooting of problems arising in a network.
Another drawback of the use of device-level management is that it does not address real-time performance issues at a routing path level which often arise in a network as a result of problems occurring at the device level such as congestion points and link or equipment failures. Device-level management only deals with performance issues for which the network devices are individually responsible. However, this xe2x80x9cdevice-level viewxe2x80x9d does not provide a path-level understanding of the overall real-time performance of all the devices defining a particular path of a particular route.
For example, in correcting a congestion problem, device-level management does not address whether the data transmitted on a particular source-destination route follows the intended path which may have been specifically provisioned for it or whether it has been rerouted to an alternate path.
When traffic is rerouted due to a failure in the network, another real-time performance issue not addressed by device-level management is whether the alternate path chosen has the requisite capacity for accommodating the traffic delayed or interrupted or whether the traffic as redirected will maintain the same level of service it had prior to being redirected. As network routes are currently sold to network clients with a specific quality of service (QoS), adequate configuration and path provisioning of network routes is becoming increasingly important. Therefore, there is a need for providing a network with adequate real-time performance monitoring and path provisioning capability for maintaining performance in a network and meeting ever increasing QoS demands.
The need to deal with device-level problems in a more time-efficient manner and address real-time performance issues arising as a result of the occurrence of device-level problems has triggered the emergence of what is now known in network management as trace routing. Trace routing applications allow some form of network-level management of paths and routes by relying on test messages to perform path discovery of specified routes. In particular, current trace routing implementations determine the path likely to be followed by traffic for a particular source-destination route by sending one or more test packets from the source node to the destination node and summarizing the results. However, this method has a number of disadvantages. First, the trace routing of any given source-destination route can only be performed from the source node. Another disadvantage is that most network devices are not properly instrumented to do this function and do not treat the test packets with the same priority than normal traffic. Therefore, the results obtained with this method are not truly representative of how the network devices handle their respective traffic in real-time. As a result, there has been a need for an improved network management system for managing and monitoring paths and routes in a network and also for monitoring the behaviour of network devices in real-time.
A solution to this problem has recently been proposed in U.S. application Ser. No. 09/288,565 filed Apr. 9, 1999 entitled xe2x80x9cRoutes and Paths Managementxe2x80x9d to Mark Robinson and Larry Franko assigned to the same applicant as this application which teaches a method and apparatus whereby information pertaining to the paths traversed in particular routes can be obtained. This application is hereby incorporated by reference in its entirety. The information is collected by polling the individual network elements and performing some manipulation of the data thus obtained to determine the paths taken for a particular route between two points in a network, for example between two IP addresses. This allows path and route level network management to be performed. This has provided a substantial improvement over the state-of-the art discussed above in which device-level management is performed.
Referring now to FIG. 2, a flowchart for a very simplified version of the method taught in the above-identified U.S. patent for the collection of data from a network is displayed. Firstly, the raw data is collected from the network using conventional network management data collection techniques. Next, this data is processed so as to identify paths of selected routes, and then the data is stored as a function of time in association with the identified paths and routes in a database.
While the above referenced application teaches how the route and path information may be collected, this is such a departure from the conventional information made available to network management applications that conventional GUI (graphical user interfaces) are incapable of making an effective use of this information. It would be advantageous to have a GUI which effectively makes use of the improved route and path information in order to allow a user to quickly assess the overall health of the network.
It is an object of the invention to obviate or mitigate one or more of the above identified disadvantages and shortcomings of current network management applications.
The invention provides a network management method for managing routes in a network, preferably routes between pairs of end points taking multiple different paths. To begin, device level status and performance information is collected from the network and transformed into path and route information, for example using techniques such as taught in the above referenced patent to Robinson et al. Next, from the path and route information parameters which characterize the state of each of the routes are computed. Next, the parameters of each of the routes are displayed graphically. This allows a user to obtain a quick visual identification of the state of all of the routes in the network.
According to another broad aspect, the invention provides a network management graphical user interface method in which a 3-D representation of three axes is displayed, each axis pertaining to a respective one of three route parameters. On these three axes, for each route a parameter point representing the routes parameters is displayed as a function of time.
Preferably, an instantaneous direction for each parameter is computed, and the display of each parameter point is done in a manner from which the instantaneous direction of the parameter point can be visually ascertained. Also preferably, each parameter point may be displayed in a manner indicative of the rate of change of the corresponding parameter point.
Preferably, each parameter point is displayed in the form of a cone having a central axis pointing in the instantaneous direction of the parameter point, and which has a length which is proportional to the rate of change of the corresponding parameter point.
A user can select a particular parameter point upon which further details in relation to the corresponding route are displayed. The further details may for example be the three parameters for the particular route displayed individually. When a parameter point is selected, preferably a cuboid is displayed which allows the determination of the location of the parameter points. Markers indicating where the particular parameter point""s parameters are on each of the three axes may be displayed.
Preferably, the parameter points are displayed in a first colour if all of the parameters are within an acceptable operating range, and are displayed in a second colour if at least one of the parameter points are outside the acceptable operating range. More generally, the parameter points may be displayed with first and second characteristics.
The display displays the parameter points as they exist at a particular point and time. A user may select a particular time for which the parameter points are to be displayed. Furthermore, an animated display for parameters updated between a first and second time may be produced. The advancement of the display between a first time and a second time may be controlled by dragging a selected time indicator between a first time and a second time on a time bar, for example.
In the event that real-time updating is requested, the display may be updated in real-time to reflect a most recent set of parameters.